1. Field of the Invention
This invention relates to an improved method and device for assessing the integrity of computer software during the system initialization process, and preventing incorrect programs from executing. Preferred embodiments of this invention relate to an improved user authentication method, and generally improved computer system security. The invention is useful for preventing damage from certain computer virus and Trojan horse attacks.
2. Background Discussion
The field of computer security spans many interrelated areas, addressing many different problems. Defensive security protective measures can often be quite complex, and in complex systems, an attacker can exploit a "weak link" in the system to circumvent the protective measures. The security of one aspect of the system can thus depend on the strength of protection provided in other areas. This invention primarily assesses software integrity at startup time, and it is intended to enhance rather than replace other security methods. Since it can compensate for other security weaknesses of the system, the resulting benefits go beyond integrity assessment to improve user authentication and other security functions.
As this invention provides the greatest benefit in personal computer systems, the IBM-compatible personal computer (herein after referred to simply as the "PC") running the DOS operating system will be used as an example for much of this discussion. But the same benefits can be realized in other computer operating systems and hardware, and appropriately modified implementations will be apparent to those skilled in the art.
As this invention is related to the fields of software protection, software integrity assessment, cryptography, memory protection, and user authentication, we will discuss relevant prior art in each of these areas. The invention includes a unique application of prior art in cryptography and integrity assessment. To clarify the relationship between the relevant fields, we first define some concepts in computer security as used herein, including "trusted software", software "integrity" and software "protection". We will also review some specific security threats including "Trojan horse" and "software virus" attacks, and review the prior art in addressing these threats, distinguishing between protection methods and integrity assessment methods, and describing the useful concept of a "trusted path".
"Trusted software", as used here, is defined to be the subset of all the software used in a system, which is responsible for the correct and reliable operation of the system, and responsible for enforcing a system's security policy. The security policy may include rules for how to authorize access to the system, and rules for determining who can access particular data within the system. The "trust" here is an abstract relative measure. The determination of which software is trusted, and the functions which it is trusted to perform, can vary widely from system to system. Our usage of the term "trusted software" is closely related to the usage in standard computer security literature, including the U.S. Department of Defense Trusted Computer System Evaluation Criteria (TCSEC). In this literature, the term "trusted computing base" is often used, which is comprised of the trusted software, plus any supporting hardware.
Software "integrity", as used in this discussion, refers to whether the software is as trustworthy as when it was initially installed. We assume that the system is in its most reliable state immediately after a proper installation. System software that has been changed, whether through a deliberate act by unauthorized person, or through an accidental system malfunction, is said to have undergone an "integrity violation". In such cases, the software should no longer be presumed to operate correctly. Maintaining the integrity of the trusted software is especially important. "Integrity assessment" is the art of determining whether a system's integrity is intact or has been violated. The "trusted software" referred to throughout this discussion is generally trusted at least to not violate the integrity of other parts of the system.
We now introduce an extension to the concept of trusted software, to be called "transient trusted software". This concept applies to systems that startup in a highly trusted state and degrade over lime. At a certain point in the operation of a system, the set of trusted software may become vulnerable to attack, and can no longer be relied upon to perform trusted operations. When the system is restarted, integrity assessment measures can be used to revalidate the transient trusted software. In the rest of this document, our use of "trusted software" will generally refer to this "transient trusted software".
Software "protection" is defined here as the art of preventing violations of software integrity. Although this invention is primarily an integrity assessment method, rather than a software protection method, a review of some protection methods will help frame the invention in the context of prior art. The discussion will show how software protection methods in actual use are less than perfect, and how a stronger layer of integrity assessment is needed. (The field of software "protection" should not be confused with the field of software "copy-protection", which addresses the problem of software theft.)
One general class of threat to system security is a "Trojan horse" attack. This is a program that is designed or has been modified to perform some hostile act, but is disguised as a familiar or non-threatening program, or it may be hidden within trusted system programs.
Another general class of security threat is the "software virus". These are hostile software programs, often introduced into systems using a Trojan horse method, with the additional ability to replicate by attaching copies of themselves into other modified programs. These attacks first violate the integrity of software, and then perform a hostile action at a later time.
Whereas the wide-spread threat from software viruses is a relatively new phenomenon, historically, much attention in the computer security field has focused on methods to protect computer system integrity while allowing untrusted programs to run. The field of software protection has generated many mechanisms for securing access to software and data within a system. Multi-ring architectures were designed both to segregate user processes from each other in multi-user time sharing systems, and to protect trusted operating systems from less-trusted applications. In these systems, special hardware and software mechanisms segregate the software address space into two or more protection "rings". The innermost ring contains the system's most-trusted software, and can enforce some of the security policy even in the face of failures of software in outer rings. A good background discussion of protection rings, and a description of an advanced multi-ring architecture can be found in U.S. Pat. No. 4,787,031.
However, despite the architectural strength of some systems, in actual use, the integrity of trusted software cannot always be guaranteed. In the UNIX operating system, which uses a two-ring architecture, there is a facility for "root" access for processes running in the less-privileged outer ring. With root access, much of the architectural surrounding the inner ring can be bypassed, and any user or process running as root can modify any trusted software. In theory, root access is only used for special security-sensitive operations, but in practice, preventing unauthorized root access is a well-known security problem of the system.
In IBM-compatible PC system running DOS, which uses the processor's ringless "real" addressing mode, the problem is much worse. There is no architectural constraint preventing any application from corrupting the rest of the system software. Since all DOS programs have access to the same address space as DOS itself, all writable storage areas of the machine are vulnerable to attack. This problem remains even in PC operating systems that switch between real and protected addressing modes of the Intel 386 family of microprocessors, which is discussed in U.S. Pat. No. 4,825,358. (This patent is also cited below in the discussion of prior art in memory-protection devices.) Since such systems generally still provide access to real mode, and for other compatibility reasons, there is always a back-door for bypassing the security features set up in protected mode.
The threat of very sophisticated deliberate attacks against system security has also become a common problem. There is much literature about the problem of PC viruses, and many products have been designed to mitigate their threat. A particularly troublesome form of virus attack is one that is carefully designed to bypass normal system security features. And though there may be no deliberate attempt to infect a given system, there is still a high risk of inadvertent infection.
Because PC DOS systems have no solid memory protection architecture, all writable storage areas of the machine are thus vulnerable to attack. Some examples of vulnerable areas in a PC include the following:
a writable hard disk; PA0 a removable disk, where unauthorized substitution of, or access to the disk is possible; PA0 an inadequately protected storage area on a network server that contains a program to be downloaded to a PC; PA0 a PC which loads downloads a program into memory from another machine across a network, where the network or the network download protocol has inadequate protection.
To mitigate the virus threat, a wide variety of products have been designed to detect, prevent, and remove viruses. Though prevention of a virus attack is beyond the scope of this invention, part of the need for this invention is that no purely preventive solution is 100% effective, especially in typical PC systems. Software-only protective measures can only offer a limited form of assurance against malicious attack, generally because the protection software and the virus must share the same address space. The protection software is thus vulnerable to a virus attack designed to specifically target the protection program. Thus, even if an existing software product perfectly protects against all current viruses, there is no guarantee that a new virus will not be developed to circumvent the product, and escape detection. Some of the anti-virus products on the market use special hardware to address the problem, but these generally focus on preventing virus infection, rather than assessing integrity. And both hardware and software-only products often rely on the secrecy of the product design or implementation. A virus developer can discover secret design details by reverse engineering the product, and a software attack can be designed to circumvent these solutions.
The field of virus detection provides another level of defense against viruses. If a virus infection has already occurred, it is often possible to detect and remove the virus before more serious damage can occur. This field is related to the more general field of software integrity assessment. Some methods of virus detection, such as searching for data patterns indicating the presence of specific viruses, cannot be used as a general integrity test. But a strong integrity assessment test can offer strong proof that no virus has infected a given program. The use of "modification detection codes", discussed further below, provides a strong test for integrity and viruses.
Software viruses are only one class of security threats that can be introduced to a system with a Trojan horse attack. Other threats include attacks directed at obtaining security-sensitive data, such as passwords.
Accidental corruption of the PC system is also a common problem, typically resolved by a system restart. Somewhat less commonly, a copy of an operating system on disk becomes corrupted, and if the system restarts without detecting the corruption, further damage may occur. Our invention can also detect such accidental system failures.
The "trusted path" feature is an important component of secure systems, designed specifically to eliminate Trojan horse and other threats during security-critical operations, such as a login process. A trusted path unambiguously establishes a secure connection between the user's input device and a trusted program, such that no other hardware or software component can intervene or intercept the communication. This is sometimes implemented with a reserved keyboard key known as the "secure attention key", as is described in U.S. Pat. No. 4,918,653. Trusted path is a required feature of systems evaluated against higher levels of the U.S. Department of Defense TCSEC security standard. The European ITSEC has similar requirements, and there is recent recognition that "trusted path" is needed as a minimal requirement for secure general-purpose commercial systems. One form of this invention provides a trusted path to a login program, using the PC's reset switch as a secure attention key.
Much of the preceding background has suggested a need for integrity assessment methods, and there is relevant prior art in this field as well. A widely used technique is to compute an integrity assessment code on a program, and verify that the code matches a predetermined value before executing the program. We will discuss two different approaches for computing the integrity assessment code, namely checksums and modification detection codes.
Within the PC, the BIOS program which resides in read-only memory (ROM) is the first program to run when the system starts up. As part of its initialization it looks for other ROM extensions to BIOS, and verifies the checksum of these extensions programs before allowing them to be used. This is described in "IBM PC Technical Reference--System BIOS". U.S. Pat. No. 5,022,077, also uses checksums to validates extensions to the PC BIOS program where the extensions reside outside of the ROM. But the real focus of their patent is on protecting the storage area where BIOS extensions are kept, rather than verifying their integrity. And their storage protection method shares the architectural weakness of most software-controlled protection schemes on the PC.
U.S. Pat. No. 4,975,950 claims the invention of checking a system for the presence of a virus at system initialization, and preventing operation if a virus is found. But, rather than defining a virus-detection technique, or an integrity assessment method as in our invention, it uses only "known techniques for checking file size, file checksum, or file signature".
Although checksums are adequate for detecting accidental modifications of data, they are an insecure defense against deliberate modification. It is in fact very easy to modify a message such that it retains the same checksum value, and whole classes of more complex algorithms, including cyclic redundancy checks, suffer from the same problem. To address this problem, "modification detection codes" have been designed to specifically detect deliberate corruption of data, and are superior to earlier methods, such as checksums. Whereas data can be intentionally modified in a manner that preserves a chosen checksum, it is intended to be computationally infeasible to modify data so as to preserve a specific modification detection code value. The security of a good modification detection code algorithm may depend on solving a particularly difficult unsolved mathematical problem, one that has withstood prolonged serious attention by experts in cryptography and mathematics. Modification detection codes are also known by other names in the literature, including: "cryptographic checksum", "cryptographic hash", "secure hash algorithm", and "message digest". There has also been recent progress in finding strong, yet efficient algorithms, including a recent proposed standard algorithm described in "National Institute of Standards and Technology--Proposed FIPS for Secure Hash Standard", Federal Register, Jan. 1992, page 3747.
Modification detection codes are also commonly used in conjunction with the use of "public-key digital signatures", which can authenticate the originator of a message. Creating a digital signature for a message often involves computing a modification detection code for the message, and then a further computation that "signs" the code with a private key held only by the originator of a message. A public-key that corresponds to the originator's private key is made widely available. The signature can be then be verified by any person who has access to the originator's public-key, with a computation that uses the modification detection code, the signature, and the public-key. The digital signature technique, a popular example of which is described in U.S. Pat. No. 4,405,829 ("RSA"), is used in an enhanced form of our invention.
Modification detection codes have also been applied to the problem of virus protection on PCs. Recent software products compute modification detection codes on programs and verify them prior to program execution. But software-only protection schemes for PCs suffer from the problem of residing in the unprotected address space. A potential solution is to embed the modification detection code in a permanent read-only memory device, but this makes system reconfiguration quite difficult. Other methods used in software products keep the modification detection code algorithm secret, and take measures to hinder the "reverse engineering" of the protection software. The weaknesses here are that it is difficult to predict how secrecy will be maintained, especially since reverse engineering is not a mathematically intractible problem. Other product announcements have described software-only verification systems using public-key digital signatures, in addition to modification detection codes, to verify programs.
Our invention uses a combination of known techniques, as described above, but it further incorporates a new hardware memory protection latch to make security mechanisms immune to software attack. One result is that our integrity assessment method is immune to the kind of violations it is intended to detect. A review of prior art in memory protection is therefore appropriate.
In this field, a wide variety of software and hardware methods allow the memory address space to be partitioned and allow control over which software has access to individual regions of the memory. These methods generally allow trusted software to both enable and disable the protection mechanism for a given region of memory, and these methods are often tied to central features of the architecture of the systems central processor unit (CPU). The memory protection method in our invention is partly distinguished by only allowing software control in one direction: from unprotected to protected mode.
An add-on memory protection method, structurally similar to the one in our invention, but allowing two-way switching, is described in U.S. Pat. No. 4,388,695. The previously mentioned U.S. Pat. No. 4,825,358 also briefly describes memory protection hardware for a PC, which uses software to enable and disable the protection.
Other patented, memory protection schemes that have used a one-way switching latch have been either in the opposite direction, that is only from protected mode to unprotected mode, as in U.S. Pat. No. 4,651,323, or have been designed for a different purpose and are triggered by a different mechanism, as in U.S. Pat. No. 4,685,056.
In the field of user authentication, many methods have been developed, including the common, and often controversial, use of passwords. Rather than review these methods in detail here, the relevant fact is that almost all methods require access to secret user-specific authentication data during the authentication process. To minimize the threat of secret passwords being revealed, it is generally recognized that passwords should be stored in a one-way hashed form to thwart attacks that look for them. But even one-way hashed passwords should be kept secret in order to thwart "brute-force" computational attacks on the known hashed password. Such attacks are especially easy if the password is poorly chosen. The Department of Defense Password Management Guideline--CSC-STD-002-85, April 1985, discusses many of these issues.
In PC systems, there are many products that use passwords. Of particular interest here are systems that require a password for initial startup of the system, sometimes implemented within the ROM BIOS. Some BIOS password implementations keep a hashed form of the password in an unprotected readable and writable non-volatile memory used to store configuration data, known as the "CMOS RAM", and thus the stored hashed passwords are vulnerable to being read or written by untrusted applications.
In general, integrity assessment is needed in many systems because no purely preventive measures can guarantee that a system will never be corrupted. Even systems that use protected addressing modes have complexities that can be explored to attack system integrity. A natural time to check system integrity is at startup, and a startup integrity check is particularly beneficial for personal computers since they can be restarted frequently.
The concept of transient trusted software has been introduced to allow systems without a strong protection architecture to nevertheless use strong security methods during system initialization. Our invention assesses the integrity of the trusted software, to discover any corruption as the system starts. The combined hardware and software approach used here makes this method immune to software-only attack, and the security of this method does not depend on keeping secret the design details of either the software or the hardware. This additional integrity guarantee is best used in combination with traditional protection methods to enforce a wide range of security policies.
Standards for evaluating computer system security, such as the TCSEC, require a high level of assurance for a product to be rated at the upper levels. Such systems may be analyzed against a mathematical model of security, and may involve formal proof techniques. The nature of the design of this mechanism suggests that such an analysis may be possible.
In light of this discussion of the prior art, the aforementioned problems with existing security solutions, the need for strong measures to verify the integrity of computer system software, and the need for storing secret authentication data, we proceed to describe this invention. Particular preferred embodiments of the invention on an IBM PC are described here to provide additional protection against certain PC viruses, a "trusted path" login procedure, and an improved means of maintaining the secrecy of stored authentication data.